當到了中鳥階段，表示已經工作了至少一年以上，對程式開發的工作有了最起碼的經驗，當然大多數都是 Coding 比較多，但是從中鳥階段開始，要接觸的可能就不只是 Coding，其中一項就是和使用者談需求。
如果是在中小企業工作，在一人分飾多角的情況下，很難不和使用者面對面接觸，有些人可能在菜鳥階段就要和使用者直接面對，但通常沒有一些實務經驗的話，公司不太會派菜鳥去和使用者接觸的，一來是因為經驗不足，二來也是怕會對使用者的需求發生誤判，以致於系統設計的方向偏掉或不正確，和使用者確認的時間也會跟著拉長，專案時程也會受到影響。當然，通常談需求這件事都是由業務或企畫出馬的，只是為了確保技術的可行性，在一些需要較高技術面的案子，業務會帶著技術人員一起參與，由技術人員提供專業的意見，以判斷功能需求的可行性。

只是多數使用者其實都不知道自己要的是什麼，只憑一些簡單的記憶，或是去某某網站看看，就把功能劃進專案中，通常是不會想到可行性的，例如畫面上要加什麼欄位啦，哪個功能必須要有某某能力啦，報表一定要有什麼圖 (即便該圖和資料一點關係都沒有) 之類的，這在一些形象或是公司門面 (ex: Portal) 會更明顯，尤其是視覺的設計上。

只是以程式開發的角度而言，虛無漂渺的需求無助於系統的開發，反而有可能會誤導 SA/SD 設計出與需求完全不同的系統，就像這張圖一樣：

(Source: http://roger-deliah.blogspot.com/2008/01/blog-post_18.html)

只是，要使用者自己說出真正的需求，在大多數情況下是幾乎不可能的，所以身為一位需求擷取的人員，除了一些系統分析與設計的教科書上提的方法外，基本上還需要一些技巧，才能由使用者的身上挖出真正的需求，例如：

1. 由使用者描繪流程，並以流程圖來確認。
2. 由使用者提供表格，並和使用者討論欄位，以作為表單設計的依據。
3. 用引導的方式，由使用者提出的需求中萃取出真實的需求。
4. 畫一些草圖，並與使用者討論畫面布局。
5. 提供一些範本或案例，由使用者挑選最接近的，再討論出真實的需要。

在挖需求時，圖說是很重要的，古人云 "一圖勝千言"，如果有圖可以輔助的話，使用者看得到畫面也比較容易判斷與確認，而程式師在設計程式時，也有一些流程和布局上的依據。這些經驗都是需要真實的去和使用者接觸，才能夠累積的。所以如果有機會去見客戶談需求時，不要急著推掉，因為它在未來會成為在無形中正確判斷使用者需求所需要的經驗。

More Reference:
http://www.bestwise.com.tw/_trial_files/52mit00604/ch03.pdf